1. Field of the Invention
The present invention relates to the field of network security and more particularly to security enforcement point processing of encrypted data in a communications path.
2. Description of the Related Art
Internet security has increasingly become the focus of information technologists who participate in globally accessible computer networks. In particular, with the availability and affordability of broadband Internet access, even within the small enterprise, many computers and small computer networks enjoy continuous access to the Internet. Notwithstanding, continuous, high-speed access is not without its price. Specifically, those computers and computer networks which heretofore had remained disconnected from the security risks of the Internet now have become the primary target of malicious Internet malfeasors.
To address the vulnerability of computing devices exposed to the global Internet, information technologists intend to provide true, end-to-end security for data in the Internet through secure communications. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols which provide secure communications on the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. There are slight differences between SSL 3.0 and TLS 1.0, but the protocol remains substantially the same. In operation, TLS involves two processing phases. First, there is a key exchange or “handshake” phase, in which the server and client attempt to agree upon an encryption suite to be used for data transmission. Subsequently, a bulk encryption or data transmission phase is carried out in which the desired content is transmitted using the agreed-upon encryption suite.
The secured communications path defined between two TLS endpoints often incorporate one or more security enforcement points such as a virtual private network (VPN)/firewall. Security enforcement points generally are no different than any other computing device excepting that the computing device supporting a security enforcement point hosts logic including program code enabled to support security services such as IP packet filtering, intrusion detection, load balancing and quality of service (QoS) setting management. Yet, where a security enforcement point has been positioned in the midst of a TLS secure communications path, the enforcement point will have no access to cleartext data in traversing data. Consequently, the security function of a security enforcement point in a secure TLS communications path will have become inoperable as most security functions require access to unencrypted, cleartext data.
In response, customers often choose between not running encryption (or at least not for the entire communications path), or running encryption on a hop-by-hop basis so that cleartext is available at the enforcement points. In the latter circumstance, even if the entire communications path has been protected end-to-end in a hop-by-hop configuration, the authentication as a whole is not end-to-end. Rather, a given node authenticates only to the next hop node. Additionally, in the hop-by-hop configuration, the TLS server key and certificate along with the private key and certificate must be stored at each enforcement point—an undesirable outcome.
Other TLS proxy methods have been proposed to provide security gateways and SSL aware enforcement points. These proposals usually involve sharing the private key and certificate of the TLS server endpoint, where the private key is used to monitor the session, or terminating the client to server session in the enforcement point (hop-by-hop encryption). Additionally, yet other key recovery schemes have been proposed to save the keys from TLS session in central key recovery server so that the clear text of the recorded TLS session could be recovered at a later time.